No-block zone costs in space and time for autonomous vehicles

ABSTRACT

Aspects of the disclosure provide for controlling an autonomous vehicle using no block costs in space and time. For instance, a trajectory for the autonomous vehicle to traverse in order to follow a route to a destination may be generated. A set of no-block zones through which the trajectory traverses may be identified. A no-block zone may be region where the autonomous vehicle should not stop but can drive through in an autonomous driving mode. For each given no-block zone of the set, a penetration cost that increases towards a center of the no-block zone and decreases towards edges of the no-block zone may be determined. Whether the autonomous vehicle should follow the trajectory may be determined based on the penetration cost. An autonomous vehicle may be controlled in the autonomous driving mode according to the trajectory based on the determination of whether the autonomous vehicle should follow the trajectory.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 17/382,449, filed Jul. 22, 2021, the entire disclosure of whichis incorporated herein by reference.

BACKGROUND

Autonomous vehicles, for instance, vehicles that may not require a humandriver, can be used to aid in the transport of passengers or items fromone location to another. Such vehicles may operate in a fully autonomousmode where passengers may provide some initial input, such as a pickupor destination location, and the vehicle maneuvers itself to thatlocation. Thus, such vehicles may be largely dependent on systems thatare capable of determining the location of the autonomous vehicle at anygiven time, as well as detecting and identifying objects external to thevehicle, such as other vehicles, stop lights, pedestrians, etc.

BRIEF SUMMARY

Aspects of the disclosure provide a method controlling an autonomousvehicle. The method includes generating, by one or more processors, atrajectory for the autonomous vehicle to traverse in order to follow aroute to a destination; identifying, by the one or more processors, aset of no-block zones through which the trajectory traverses, wherein ano-block zone is region where the autonomous vehicle should not stop butcan drive through in an autonomous driving mode; for each given no-blockzone of the set, determining, by the one or more processors, apenetration cost such that the penetration cost increases towards acenter of that given no-block zone and decreases towards edges of thatgiven no-block zone; determining, by the one or more processors, whetherthe autonomous vehicle should follow the trajectory based on thepenetration cost; and controlling, by the one or more processors, theautonomous vehicle in the autonomous driving mode according to thetrajectory based on the determination of whether the autonomous vehicleshould follow the trajectory.

In one example, the penetration cost is determined further based on atype of the given no-block zone. In another example, the method alsoincludes aggregating the penetration costs for each no-block zone of theset, and wherein determining whether the autonomous vehicle shouldfollow the trajectory is further based on the aggregated penetrationcosts. In another example, the method also includes generating a secondtrajectory the autonomous vehicle to traverse in order to follow theroute; identifying a second set of no-block zones through which thesecond trajectory traverses; and for each given no-block zone of thesecond set, determining a second penetration cost such that the secondpenetration cost increases towards a center of that given no-block zoneof the second set and decreases towards edges of that given no-blockzone of the second set, and determining whether the autonomous vehicleshould follow the trajectory is further based on the second penetrationcost. In this example, determining whether the autonomous vehicle shouldfollow the trajectory further includes comparing the penetration cost tothe second penetration cost. In addition or alternatively, the methodalso includes aggregating the penetration costs for each no-block zoneof the set; and aggregating the second penetration costs for eachno-block zone of the second set, and determining whether the autonomousvehicle should follow the trajectory further includes comparing theaggregated penetration costs and the aggregated second penetrationcosts.

In another example, the trajectory includes the autonomous vehicletraversing one or more edges of a road graph, and the method alsoincludes determining a second cost for the trajectory based on thepenetration cost and an expected speed of the autonomous vehicle whiletraversing an edge of the trajectory according to the trajectory. Inthis example, the edge passes through at least one no-block region ofthe set, and wherein determining whether the autonomous vehicle shouldfollow the trajectory is further based on the second cost. In addition,determining the second cost for the trajectory is further based on anexpected amount of time for the autonomous vehicle to traverse the edge.In addition, traversing the edge involves the vehicle entering andcompletely exiting the edge. In addition or alternatively, determiningthe second cost for the trajectory is further based on whether theexpected speed of the autonomous vehicle while traversing the edge isgreater than a threshold value. In this example, the method alsoincludes determining the threshold value based on a type of the no-blockregion through which the edge passes. In another example, the trajectoryincludes the autonomous vehicle traversing one or more edges of a roadgraph, and the method also includes determining a second cost for thetrajectory based on the penetration cost and an expected amount of timethat the autonomous vehicle would be stopped at the start of an edgeaccording to the trajectory.

Another aspect of the disclosure provides a system for controlling anautonomous vehicle. The system includes one or more processorsconfigured to generate a trajectory for the autonomous vehicle totraverse in order to follow a route to a destination; identify a set ofno-block zones through which the trajectory traverses, wherein ano-block zone is region where the autonomous vehicle should not stop butcan drive through in an autonomous driving mode; for each given no-blockzone of the set, determine a penetration cost such that the penetrationcost increases towards a center of that given no-block zone anddecreases towards edges of that given no-block zone; determine whetherthe autonomous vehicle should follow the trajectory based on thepenetration cost; and control the autonomous vehicle in the autonomousdriving mode according to the trajectory based on the determination ofwhether the autonomous vehicle should follow the trajectory.

In this example, the penetration cost is determined further based on atype of the given no-block zone. In another example, the one or moreprocessors are further configured to aggregate the penetration costs foreach no-block zone of the set, and wherein the determining whether theautonomous vehicle should follow the trajectory is further based on theaggregated penetration costs. In another example, the one or moreprocessors are further configured to generate a second trajectory theautonomous vehicle to traverse in order to follow the route; identify asecond set of no-block zones through which the second trajectorytraverses; and for each given no-block zone of the second set, determinea second penetration cost such that the second penetration costincreases towards a center of that given no-block zone of the second setand decreases towards edges of that given no-block zone of the secondset. In addition, determining whether the autonomous vehicle shouldfollow the trajectory is further based on the second penetration cost.In another example, the trajectory includes the autonomous vehicletraversing one or more edges of a road graph, and the the one or moreprocessors are further configured to determine a second cost for thetrajectory based on the penetration cost and an expected speed of theautonomous vehicle while traversing an edge of the trajectory accordingto the trajectory. In addition, the edge passes through at least oneno-block region of the set, and determining whether the autonomousvehicle should follow the trajectory is further based on the secondcost. In this example, the one or more processors are further configuredto determine the second cost for the trajectory further based on anexpected amount of time for the autonomous vehicle to traverse the edge.In addition or alternatively, the one or more processors are furtherconfigured to determine the second cost for the trajectory further basedon whether the expected speed of the autonomous vehicle while traversingthe edge is greater than a threshold value. In another example, thetrajectory includes the autonomous vehicle traversing one or more edgesof a road graph, and the one or more processors are further configuredto determine a second cost for the trajectory based on the penetrationcost and an expected amount of time that the autonomous vehicle would bestopped at the start of an edge according to the trajectory.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional diagram of an example vehicle in accordance withan exemplary embodiment.

FIG. 2 is an example representation of map information in accordancewith aspects of the disclosure.

FIG. 3 is an example external view of a vehicle in accordance withaspects of the disclosure.

FIG. 4 is an example representation of map information and a trajectoryin accordance with aspects of the disclosure.

FIG. 5 is an example representation of a no-block zone and data inaccordance with aspects of the disclosure.

FIG. 6 is an example representation of a no-block zone and edges inaccordance with aspects of the disclosure.

FIG. 7 is an example representation of a cost function in accordancewith aspects of the disclosure.

FIG. 8 is an example flow diagram in accordance with aspects of thedisclosure.

DETAILED DESCRIPTION Overview

The technology relates to controlling autonomous vehicles in order toavoid stopping or moving too slowly through certain types of areas. Forinstance, there are certain “no-block zones” areas within which avehicle should avoid stopping such as railroad crossings, crosswalks,intersections, across a lane of traffic, and regions specificallydesignated as no stopping zones (areas designated by “Don't Block theBox” or “Keep Clear” signs or indicators). Each no-block zone may bedefined in map information used by such autonomous vehicles, forinstance, as a line having a pair of end points or a polygon havingthree or more edges. Current approaches for avoiding such no-block zonesmay involve autonomous vehicles making a binary “yes” or “no”determination for violating (e.g. entering into) a no block zonetherefore causing such vehicles to stop the vehicle using a hard brakingmaneuver, increase the vehicle's speed to avoid the no block zone, orpotentially ignoring the no block zone and stopping within it. However,it may not always be possible to stop outside of such no-block andmoreover, it may be more dangerous to stop the vehicle using a hardbraking maneuver or increase the vehicle's speed to avoid a no-blockzone than to stop a few inches within the no-block zone.

The vehicle's computing devices may utilize pre-stored map informationin order to control the vehicle within a driving environment. The mapinformation may be configured as a roadgraph which includes a pluralityof graph nodes and edges representing road or lane segments thattogether make up the road network of the map information. Each edge isdefined by a starting graph node having a specific geographic location,an ending graph node having a specific geographic location, and adirection. This direction may refer to a direction the autonomousvehicle 100 must be moving in in order to follow the edge.

The pre-stored map information may thus include highly detailed maps ofa vehicle's expected environment as well as information identifying theshape and location of the no-block zones. Alternatively, some no-blockzones may be detected in real time, by detecting signs or indicators(such as keep clear markings on a roadway which allow vehicles fromminor roadways or driveways to make a turn onto another roadway) orright-of-way and determining that these signs and indicators andright-of-way correspond to additional no-block zones.

In addition to pre-stored map information, the computing devices mayrely on information detected by the vehicle's perception system. Forinstance, the vehicle's sensors may detect and identify various objectsin the vehicle's environment as well as information such as location,speed, orientation, status, etc.

As the vehicle is maneuvered along a route to a destination, thecomputing devices may combine the map information, information from theperception system, and a route the vehicle is currently following aswell as other systems of the vehicle to generate trajectories for thevehicle to follow into the future. The trajectories may provide thevehicle with instructions for traversing a portion of the route oversome brief period of time into the future, and may also include a planto stop the vehicle, for instance, in the event a next trajectory is notgenerated or received by the vehicle's acceleration, deceleration orsteering systems.

These trajectories may be evaluated to select the trajectory having thelowest cost. Each time a trajectory is generated, a set of no-blockzones through which the trajectory passes may be identified. In someinstances, the set may be empty, and in others the set may include aplurality of no-block zones. Thus, at least some of these costs mayrelate to the trajectory's relationship with any no-block zones of theset. For instance, trajectories may be penalized based on the type orpriority of the no-block zone, an amount of penetration into theno-block zone, and the vehicle's expected speed through the no-blockzone. For instance, no-block zones may be prioritized based on type.This information may also be stored in the detailed map informationassociated with each no-block zone or elsewhere.

A penetration cost for each no-block zone may be determined based onboth the no-block zone type and the amount of penetration within thezone or how close the autonomous vehicle is to the edges of a no-blockzone. For instance, the cost may increase towards the center of theno-block zone and therefore be lower towards the edges or starting andending points of the no-block zone. Where the set includes multipleno-block zones, the penetration costs of the different no-block zonesmay be summed together. This aggregated cost may then be combined withother costs in order to assess the overall cost of the trajectory andcompare to other trajectories.

In some instances, the speed of the autonomous vehicle may also be usedto assess a cost for the autonomous vehicle passing through a no-blockzone. In this regard, the trajectory may be divided into a plurality ofnodes and edges between pairs of nodes], and a cost may be assessed foreach edge. The costs of the individual edges may be summed together.This aggregated cost may then be combined with other costs in order toassess the overall cost of the trajectory and compared to othertrajectories. In some instances, the penetration cost may be combinedwith speed characteristics of the trajectory in order to determine acost for an edge that traverses a no-block zone. Alternatively, ratherthan separately assessing the components of cost based on the time theautonomous vehicle will be stopped and the time the autonomous vehiclewill be below a certain threshold speed, a single smooth function,inversely correlated with speed may be used to capture bothcontributions to cost. In some instances, the cost of an edge may alsotake into account the hysteresis or the historical cost of an edge. Thismay be used to incentivize (e.g. lower the relative cost of) exiting ano-block zone more and more over time (across iterations).

The features described herein may allow autonomous vehicles to avoidstopping or moving too slowly through no-block zones. In addition, thecost assessments described above may reduce the likelihood of anautonomous vehicle stopping within a no-block zone closer to the centerof the no-block zone. As such, the vehicle may be more likely to stopcloser to edges of the no block-zone rather than making unsafe maneuversin order to avoid stopping within a no-block zone. In addition, becausethe features described herein penalize slower speeds through no-blockzones, this may also cause autonomous vehicles to clear no-block regionseven faster.

Example Systems

As shown in FIG. 1 , an autonomous vehicle 100 in accordance with oneaspect of the disclosure includes various components. While certainaspects of the disclosure are particularly useful in connection withspecific types of vehicles, the vehicle may be any type of vehicleincluding, but not limited to, cars, trucks, motorcycles, buses,recreational vehicles, etc. The vehicle may have one or more computingdevices, such as computing devices 110 containing one or more processors120, memory 130 and other components typically present in generalpurpose computing devices.

The memory 130 stores information accessible by the one or moreprocessors 120, including instructions 134 and data 132 that may beexecuted or otherwise used by the processor 120. The memory 130 may beof any type capable of storing information accessible by the processor,including a computing device-readable medium, or other medium thatstores data that may be read with the aid of an electronic device, suchas a hard-drive, memory card, ROM, RAM, DVD or other optical disks, aswell as other write-capable and read-only memories. Systems and methodsmay include different combinations of the foregoing, whereby differentportions of the instructions and data are stored on different types ofmedia.

The instructions 134 may be any set of instructions to be executeddirectly (such as machine code) or indirectly (such as scripts) by theprocessor. For example, the instructions may be stored as computingdevice code on the computing device-readable medium. In that regard, theterms “instructions” and “programs” may be used interchangeably herein.The instructions may be stored in object code format for directprocessing by the processor, or in any other computing device languageincluding scripts or collections of independent source code modules thatare interpreted on demand or compiled in advance. Functions, methods androutines of the instructions are explained in more detail below.

The data 132 may be retrieved, stored or modified by processor 120 inaccordance with the instructions 134. For instance, although the claimedsubject matter is not limited by any particular data structure, the datamay be stored in computing device registers, in a relational database asa table having a plurality of different fields and records, XMLdocuments or flat files. The data may also be formatted in any computingdevice-readable format.

The one or more processor 120 may be any conventional processors, suchas commercially available CPUs or GPUs. Alternatively, the one or moreprocessors may be a dedicated device such as an ASIC or otherhardware-based processor. Although FIG. 1 functionally illustrates theprocessor, memory, and other elements of computing devices 110 as beingwithin the same block, it will be understood by those of ordinary skillin the art that the processor, computing device, or memory may actuallyinclude multiple processors, computing devices, or memories that may ormay not be stored within the same physical housing. For example, memorymay be a hard drive or other storage media located in a housingdifferent from that of computing devices 110. Accordingly, references toa processor or computing device will be understood to include referencesto a collection of processors or computing devices or memories that mayor may not operate in parallel.

Computing devices 110 may include all of the components normally used inconnection with a computing device such as the processor and memorydescribed above as well as a user input 150 (e.g., one or more button,mouse, keyboard, touch screen and/or microphone), various electronicdisplays (e.g., a monitor having a screen or any other electrical devicethat is operable to display information), and speakers 154 to provideinformation to a passenger of the autonomous vehicle 100 or others asneeded. For example, electronic display 152 may be located within acabin of autonomous vehicle 100 and may be used by computing devices 110to provide information to passengers within the autonomous vehicle 100.

Computing devices 110 may also include one or more wireless networkconnections 156 to facilitate communication with other computingdevices, such as the client computing devices and server computingdevices described in detail below. The wireless network connections mayinclude short range communication protocols such as Bluetooth, Bluetoothlow energy (LE), cellular connections, as well as various configurationsand protocols including the Internet, World Wide Web, intranets, virtualprivate networks, wide area networks, local networks, private networksusing communication protocols proprietary to one or more companies,Ethernet, WiFi and HTTP, and various combinations of the foregoing.

The computing devices 110 may be part of an autonomous control systemfor the autonomous vehicle 100 and may be capable of communicating withvarious components of the vehicle in order to control the vehicle in anautonomous driving mode. For example, returning to FIG. 1 , thecomputing devices 110 may be in communication with various systems ofautonomous vehicle 100, such as deceleration system 160, accelerationsystem 162, steering system 164, signaling system 166, planning system168, routing system 170, positioning system 172, perception system 174,behavior prediction system 176, and power system 178 in order to controlthe movement, speed, etc. of autonomous vehicle 100 in accordance withthe instructions 134 of memory 130 in the autonomous driving mode.

As an example, the computing devices 110 may interact with decelerationsystem 160 and acceleration system 162 in order to control the speed ofthe vehicle. Similarly, steering system 164 may be used by computingdevices 110 in order to control the direction of autonomous vehicle 100.For example, if autonomous vehicle 100 is configured for use on a road,such as a car or truck, the steering system may include components tocontrol the angle of wheels to turn the vehicle. The computing devices110 may also use the signaling system 166 in order to signal thevehicle's intent to other drivers or vehicles, for example, by lightingturn signals or brake lights when needed.

Routing system 170 may be used by the computing devices 110 in order togenerate a route to a destination using map information. Planning system168 may be used by computing devices 110 in order to generate short-termtrajectories that allow the vehicle to follow routes generated by therouting system. In this regard, the planning system 168 and/or routingsystem 166 may store detailed map information, e.g., pre-stored, highlydetailed maps identifying a road network including the shape andelevation of roadways, lane lines, intersections, crosswalks, speedlimits, traffic signals, buildings, signs, real time traffic information(updated as received from a remote computing device), pullover spots,vegetation, or other such objects and information.

FIG. 2 is an example of map information 200 for a section of roadwayincluding intersection 202 and keep clear area identified by polygon204. In this example, the map information 200 includes informationidentifying the shape, location, and other characteristics of roadfeatures such as lane lines 210, 212, 214, 216, crosswalks 220, 222,224, sidewalks 240, and stop signs 250, 252.

In addition to the aforementioned road features, the map information mayidentify no-block zones and associated types. These features may defineareas where the vehicle 100 is able to drive through, but at which thevehicle should not stop. Each no-block zone may be defined in the mapinformation as a polygon having three or more edges with an associatedtype. For instance, intersection 202 may be associated with a no-blockzone identified by the polygon 260 which corresponds to the shape ofintersection 202. In this regard, the polygon 260 may be associated withthe no-block zone type “intersection”. Crosswalks 220, 222, and 224 mayeach be associated with a no-block zone identified by polygons 270, 272,274, respectively, corresponding to the rectangular shape of eachcrosswalk and thus, also associated with the no-block zone type of“crosswalk”. As noted above, a keep clear area is identified by polygon204 which may be associated with a no-block zone type of “keep cleararea”. Other no-block zones may be identified based on the route thatthe vehicle is following, such as where the vehicle crosses over a laneof traffic to reach another lane of traffic (see the discussion belowregarding FIGS. 8A and 8B). Alternatively, some regions may be detectedin real time, by detecting signs or indicators (such as markings on aroadway) and determining that these signs and indicators correspond toadditional no-block zones.

In some instances, no-block zones may be associated with even moredetailed information about their configuration. For instance, a polygon204 may represent a “Keep Clear” area in the map information 200.However, referring to FIG. 6 , depicting a bird's eye view of thesection of roadway corresponding to the map information 200, theorientation of the text as well as the painted stop lines show theintent that a vehicle at point A moving towards point B should not blockthe keep clear area if other vehicles ahead come to a stop, but a secondvehicle moving from point C to point D and into the keep clear area doesnot need to observe this restriction as vehicles such as the secondvehicle are the reason that the “Keep Clear” area exists at all. In thisregard, the polygon 204 may be associated with information identify thedirection of traffic that needs to observe the keep clear areaidentified by polygon 204 and the direction of traffic that does notneed to observe the keep clear area identified by polygon 204.

In some instances, no-block zones may be prioritized based on type. Inother words, each no-block zone of the map information may be associatedwith a type. Of course, some types, such as active crosswalks andinactive crosswalks may be determined in real time based on bothinformation from the map information (identifying a keep clear areapolygon as a crosswalk) and information from the perception system(identifying whether there is a pedestrian in or proximate to thecrosswalk) in order to differentiate between an active polygon and aninactive one (such as an active crosswalk and an inactive crosswalk). Inthis regard, an active crosswalk may include a crosswalk included in themap information and where information from the perception system 174indicates to the computing devices 110 that there are pedestrians,pedestrians within a short distance of the crosswalk, or pedestriansexhibiting some behavior that would indicate that the pedestrians willenter the crosswalk such as approaching the crosswalk from a givendistance. Similarly, an inactive crosswalk may include a crosswalkincluded in the map information and where information from theperception system 174 indicates to the computing devices 110 that thereare no pedestrians in or within a short distance of the crosswalk.

Data 132 may also store a table or other organizational scheme thatrelates the types with a priority value identifying that type ofno-block zone's importance or priority relative to the other types ofno-block zones. Table 1 is an example of priority values for differenttypes of no-block zones, here shown with a range from 0.1-0.7. Of coursedifferent values and/or scales may also be used.

TABLE 1 No-Block Zone Type Priority Value Railroad crossing 0.7 Activecrosswalk 0.6 Intersection 0.5 Across a lane of traffic 0.4 Posted “KeepClear” area 0.3 Posted “Don't Block the Box” area 0.2 Inactive crosswalk0.1

For instance, no-block zones corresponding to railroad crossings mayhave a higher priority than no-block zones corresponding to activecrosswalks (where there are pedestrians, pedestrians within a shortdistance, or pedestrians exhibiting some behavior that would indicatethat the pedestrians will enter the crosswalk). Active crosswalks mayhave a higher priority than across a lane of traffic, across a lane oftraffic may have a higher priority than posted “keep Clear” or “Don'tBlock the Box” areas, and inactive crosswalks may have a lowest priorityof all. This information may also be stored in the detailed mapinformation associated with each no-block zone or elsewhere (e.g. alookup table).

In addition to the aforementioned physical feature information, the mapinformation may be configured as a roadgraph which includes a pluralityof graph nodes and edges representing road or lane segments thattogether make up the road network of the map information. Each edge isdefined by a starting graph node having a specific geographic location(e.g. latitude, longitude, altitude, etc.), an ending graph node havinga specific geographic location (e.g. latitude, longitude, altitude,etc.), and a direction. This direction may refer to a direction theautonomous vehicle 100 must be moving in in order to follow the edge(i.e. a direction of traffic or traffic flow). The graph nodes may belocated at fixed or variable distances. For instance, the spacing of thegraph nodes may range from a few centimeters to a few meters and maycorrespond to the speed limit of a road on which the graph node islocated. In this regard, greater speeds may correspond to greaterdistances between graph nodes. The edges may represent driving along thesame lane or changing lanes. Each node and edge may have a uniqueidentifier, such as a latitude and longitude location of the node orstarting and ending locations or nodes of an edge. In addition to nodesand edges, the map may identify additional information such as types ofmaneuvers required at different edges as well as which lanes aredrivable.

The routing system 166 may use the aforementioned map information todetermine a route from a current location (e.g. a location of a currentnode) to a destination. Routes may be generated using a cost-basedanalysis which attempts to select a route to the destination with thelowest cost. Costs may be assessed in any number of ways such as time tothe destination, distance traveled (each edge may be associated with acost to traverse that edge), types of maneuvers required, convenience topassengers or the vehicle, etc. Each route may include a list of aplurality of nodes and edges which the vehicle can use to reach thedestination. Routes may be recomputed periodically as the vehicletravels to the destination.

The map information used for routing may be the same or a different mapas that used for planning trajectories. For example, the map informationused for planning routes not only requires information on individuallanes, but also the nature of lane boundaries (e.g., solid white, dashwhite, solid yellow, etc.) to determine where lane changes are allowed.However, unlike the map used for planning trajectories, the mapinformation used for routing need not include other details such as thelocations of crosswalks, traffic lights, stop signs, etc., though someof this information may be useful for routing purposes. For example,between a route with a large number of intersections with trafficcontrols (such as stop signs or traffic signal lights) versus one withno or very few traffic controls, the latter route may have a lower cost(e.g. because it is faster) and therefore be preferable.

Positioning system 170 may be used by computing devices 110 in order todetermine the vehicle's relative or absolute position on a map or on theearth. For example, the positioning system 170 may include a GPSreceiver to determine the device's latitude, longitude and/or altitudeposition. Other location systems such as laser-based localizationsystems, inertial-aided GPS, or camera-based localization may also beused to identify the location of the vehicle. The location of thevehicle may include an absolute geographical location, such as latitude,longitude, and altitude, a location of a node or edge of the roadgraphas well as relative location information, such as location relative toother cars immediately around it which can often be determined with lessnoise that absolute geographical location.

The positioning system 172 may also include other devices incommunication with the computing devices 110, such as an accelerometer,gyroscope or another direction/speed detection device to determine thedirection and speed of the vehicle or changes thereto. By way of exampleonly, an acceleration device may determine its pitch, yaw or roll (orchanges thereto) relative to the direction of gravity or a planeperpendicular thereto. The device may also track increases or decreasesin speed and the direction of such changes. The device's provision oflocation and orientation data as set forth herein may be providedautomatically to the computing devices 110, other computing devices andcombinations of the foregoing.

The perception system 174 also includes one or more components fordetecting objects external to the vehicle such as other vehicles,obstacles in the roadway, traffic signals, signs, trees, etc. Forexample, the perception system 174 may include LIDARs, sonar, radar,cameras and/or any other detection devices that record data which may beprocessed by the computing devices of the computing devices 110. In thecase where the vehicle is a passenger vehicle such as a minivan, theminivan may include a laser or other sensors mounted on the roof orother convenient location.

For instance, FIG. 3 is an example external view of autonomous vehicle100. In this example, roof-top housing 310 and dome housing 312 mayinclude a LIDAR sensor as well as various cameras and radar units. Inaddition, housing 320 located at the front end of autonomous vehicle 100and housings 330, 332 on the driver's and passenger's sides of thevehicle may each store a LIDAR sensor. For example, housing 330 islocated in front of driver door 360. Autonomous vehicle 100 alsoincludes housings 340, 342 for radar units and/or cameras also locatedon the roof of autonomous vehicle 100. Additional radar units andcameras (not shown) may be located at the front and rear ends ofautonomous vehicle 100 and/or on other positions along the roof orroof-top housing 310.

The computing devices 110 may be capable of communicating with variouscomponents of the vehicle in order to control the movement of autonomousvehicle 100 according to primary vehicle control code of memory of thecomputing devices 110. For example, returning to FIG. 1 , the computingdevices 110 may include various computing devices in communication withvarious systems of autonomous vehicle 100, such as deceleration system160, acceleration system 162, steering system 164, signaling system 166,planning system 168, routing system 170, positioning system 172,perception system 174, behavior prediction system 176, and power system178 (i.e. the vehicle's engine or motor) in order to control themovement, speed, etc. of autonomous vehicle 100 in accordance with theinstructions 134 of memory 130.

The various systems of the vehicle may function using autonomous vehiclecontrol software in order to determine how to and to control thevehicle. As an example, a perception system software module of theperception system 174 may use sensor data generated by one or moresensors of an autonomous vehicle, such as cameras, LIDAR sensors, radarunits, sonar units, etc., to detect and identify objects and theircharacteristics. These characteristics may include location, type,heading, orientation, speed, acceleration, change in acceleration, size,shape, etc. In some instances, characteristics may be input into abehavior prediction system software module of the behavior predictionsystem 176 which uses various behavior prediction models based on objecttype to output a predicted future behavior for a detected object. Inother instances, the characteristics may be put into one or moredetection system software modules, such as a traffic light detectionsystem software module configured to detect the states of known trafficsignals, construction zone detection system software module configuredto detect construction zones from sensor data generated by the one ormore sensors of the vehicle as well as an emergency vehicle detectionsystem configured to detect emergency vehicles from sensor datagenerated by sensors of the vehicle. Each of these detection systemsoftware modules may use various models to output a likelihood of aconstruction zone or an object being an emergency vehicle.

Detected objects, predicted future behaviors, various likelihoods fromdetection system software modules, the map information identifying thevehicle's environment, position information from the positioning system170 identifying the location and orientation of the vehicle, adestination location or node for the vehicle as well as feedback fromvarious other systems of the vehicle may be input into a planning systemsoftware module of the planning system 168. The planning system 168 mayuse this input to generate trajectories for the vehicle to follow forsome brief period of time into the future based on a route generated bya routing module of the routing system 170. In this regard, thetrajectories may define the specific characteristics of acceleration,deceleration, speed, etc. to allow the vehicle to follow the routetowards reaching a destination. A control system software module of thecomputing devices 110 may be configured to control movement of thevehicle, for instance by controlling braking, acceleration and steeringof the vehicle, in order to follow a trajectory.

The computing devices 110 may control the vehicle in an autonomousdriving mode by controlling various components. For instance, by way ofexample, the computing devices 110 may navigate the vehicle to adestination location completely autonomously using data from thedetailed map information and planning system 168. The computing devices110 may use the positioning system 170 to determine the vehicle'slocation and perception system 174 to detect and respond to objects whenneeded to reach the location safely. Again, in order to do so, computingdevices 110 and/or planning system 168 may generate trajectories andcause the vehicle to follow these trajectories, for instance, by causingthe vehicle to accelerate (e.g., by supplying fuel or other energy tothe engine or power system 178 by acceleration system 162), decelerate(e.g., by decreasing the fuel supplied to the engine or power system178, changing gears, and/or by applying brakes by deceleration system160), change direction (e.g., by turning the front or rear wheels ofautonomous vehicle 100 by steering system 164), and signal such changes(e.g., by lighting turn signals) using the signaling system 166. Thus,the acceleration system 162 and deceleration system 160 may be a part ofa drivetrain that includes various components between an engine of thevehicle and the wheels of the vehicle. Again, by controlling thesesystems, computing devices 110 may also control the drivetrain of thevehicle in order to maneuver the vehicle autonomously.

Example Methods

In addition to the operations described above and illustrated in thefigures, various operations will now be described. It should beunderstood that the following operations do not have to be performed inthe precise order described below. Rather, various steps can be handledin a different order or simultaneously, and steps may also be added oromitted.

FIG. 8 is an example flow diagram 800 for controlling an autonomousvehicle, which may be performed by one or more processors of one or morecomputing devices, such as the processors 120 of the computing devices110 and/or other processors of the various other systems of the vehicle100 discussed above. At block 810, a trajectory for the autonomousvehicle to traverse in order to follow a route to a destination isgenerated.

As the vehicle is maneuvered along a route to a destination, thecomputing devices may combine the map information, information from theperception system, and a route the vehicle is currently following aswell as other systems of the vehicle to generate trajectories for thevehicle to follow into the future. For instance, the routing system 170may determine a route between the vehicle's current location and adestination location. This route may be used as a baseline for theplanning system 168 to generate trajectories. In this regard, thetrajectories may provide the vehicle with instructions for traversing aportion of the route over some brief period of time into the future,such as 10 seconds or more or less, and may also include a plan to stopthe vehicle, for instance, in the event a next trajectory is notgenerated or received by the vehicle's acceleration, deceleration orsteering systems. In this regard, the trajectory may include a geometrycomponent (where the vehicle is to drive) and a speed component (how tocontrol the acceleration and deceleration of the vehicle in order toachieve desired speeds).

FIG. 4 is an example representation of the map information 200 depictinga current location of the autonomous vehicle 100. In this example, theplanning system has generated a trajectory 410 which passes throughintersection 202 and maneuvers the vehicle towards a destination (notshown) according to a route generated by the routing system (not shown).

Returning to FIG. 8 , at block 820, a set of no-block zones throughwhich the trajectory traverses is identified. In this example, ano-block zone is region where the autonomous vehicle should not stop butcan drive through in an autonomous driving mode. Each time a trajectoryis generated, a set of no-block zones through which the trajectorypasses may be identified. In some instances, the set may be empty, andin others the set may include a plurality of no-block zones. Thus, atleast some of these costs may relate to the trajectory's relationshipwith any no-block zones of the set. For instance, trajectories may bepenalized based on the type or priority of the no-block zone (asdescribed above), an amount of penetration into the no-block zone, andthe vehicle's expected speed through the no-block zone.

Returning to the example of FIG. 4 , the trajectory 410 includes theautonomous vehicle passing through no-block zones including theintersection polygon 202, polygon 270, and polygon 272.

Returning to FIG. 8 , at block 830, for each given no-block zone of theset, a penetration cost is determined such that the penetration costincreases towards a center of that given no-block zone and decreasestowards edges of that given no-block zone. A penetration cost for eachno-block zone may be determined based on both the no-block zone type andthe amount of penetration within the zone or how close the autonomousvehicle is to the edges of a no-block zone. As such, returning to theexample of FIG. 4 , a penetration cost may be determined for each of theno-block zones including polygon 260, polygon 270, and polygon 272.

For instance, the penetration cost may increase towards the center ofthe no-block zone and therefore be lower towards the edges or startingand ending points of the no-block zone. For example, turning to FIG. 5 ,a no-block zone which may correspond to any of polygon 260, polygon 270,and polygon 272, is depicted. As can be seen, the costs at the initialedge (the first edge through which the autonomous vehicle 100 wouldpass) of the no block zone 520 is lowest and then increases and ishighest at the center of the no-block zone 510. Thereafter, the costdecreases towards the ending edge 522 (the second edge through which theautonomous vehicle 100 would pass) of the no-block zone 510 and is againat the lowest cost at the ending edge 522.

In this regard, the penetration cost for each no-block zone may bedetermined using the following equation:

C _(penetration)(state)=cost-weight(type)*min(dist(state, entrance),dist(state, exit))

In this example, the penetration cost of a no block zone(C_(penetration)) for a given location (state) is based on both the typeof the zone (type) as well as the minimum of the distances between thelocation and the beginning of the no-block zone (entrance) and the endof the no-block zone (exit). The cost-weight is component of the costbased on the type of the zone. For instance, cost weights for beingwithin a railroad crossing may be higher overall than costs of beingwithin an intersection. Thus, the value of cost-weight may be higher fora crosswalk than an intersection. The entrance and exit locations mayrefer to the points at which the geometry of the trajectory and/orconnected edges of a road graph would have the autonomous vehicle enteror exit the no-block zone. Where the set includes multiple no-blockzones, the penetration costs of the different no-block zones may besummed together. This aggregated cost may then be combined with othercosts in order to assess the overall cost of the trajectory and compareto other trajectories.

Returning to FIG. 8 , at block 840, whether the autonomous vehicleshould follow the trajectory based on the penetration cost isdetermined. As noted above, these trajectories may be evaluated toselect the trajectory having the lowest cost. In this regard, thepenetration cost may be combined with other costs as discussed above inorder to determine an overall cost for each determined trajectory. Theplanning system may then select the trajectory with the lowest overallcost and thereby cause the autonomous vehicle 100 to be controlledaccording to the selected trajectory.

Returning to FIG. 8 , at block 850 the autonomous vehicle is controlledin the autonomous driving mode according to the trajectory based on thedetermination of whether the autonomous vehicle should follow thetrajectory. For instance, as noted above, the computing devices 110 maycontrol the various systems of the autonomous vehicle 100 in order tocause the autonomous vehicle to follow the trajectory towards thedestination.

The example above assesses cost of a no-block zone based on location.However, the speed of the autonomous vehicle may also be used to assessa cost for the autonomous vehicle passing through a no-block zone. Inthis regard, the entire trajectory or rather the portion of thetrajectory that passes through a no-block zone may be divided into aplurality of nodes and edges between pairs of nodes (e.g. between asource node and a target node), and a cost may be assessed for each edgewithin a no-block zone. For instance, the trajectory may be divided intoa plurality of smaller distances, such as 2 meters or more or less, by“placing” a plurality of nodes or waypoints along the trajectory every 2meters or more or less. Turning to FIG. 6 , the no-block zone 510 issubdivided into 8 edges (here, edges A-J). Each of these edges startsand ends at a pair of nodes represented by circles. For example, edge Astarts at node A1 and ends in node B1, edge B starts at node B1 and endsat node C1, and so on.

In some instances, the penetration cost may be combined with speedcharacteristics of the trajectory in order to determine a cost for anedge that traverses a no-block zone. In this regard, the cost for eachedge of a trajectory that passes through a no-block zone, hereC_(edge1), may be determined using the following equation:

C _(edge1) =C _(penetration)(target node position)*I(target nodespeed)*time length of edge

In this example, the target node position represents the position of theautonomous vehicle along the trajectory when the rear of the autonomousvehicle reaches the target node of the edge. The time stopped at thestarting node represents an amount of time that the autonomous vehicleis expected to be stopped at the starting node of the edge. Thus, ifthis is zero seconds, this component of the cost of the edge goes tozero. The value of I(edge speed) represents an indicator function, suchthat if the target node speed or speed of the autonomous vehicle alongthe edge is below a threshold this component of the cost of the edgegoes to 1 and if the speed is at or above the threshold, this componentof the cost of the edge goes to zero. This threshold can be a fixed,hand-tuned value, such as 1, 5, 10 miles per hour or more or less, orcould be a function of the type of the no-block zone through which theedge traverses. For instance, the threshold value for a crosswalk may belower than the threshold value for railroad tracks, as it may be moreacceptable to spend more time traversing a no-block zone correspondingto a crosswalk than a no-block zone corresponding to a railroad track.In other words, the described approach would penalize slower speedthrough no-block zone for a railroad crossing. The time length of edgerepresents the amount of time the autonomous vehicle is expected to taketo traverse the edge, for instance from the point in time when a rear orrear axle of the autonomous vehicle traverses the source node to thepoint in time when the rear of the autonomous is expected to reach thetarget node according to the trajectory (e.g. such that the autonomousvehicle has completely traversed the edge), according to the distancebetween the nodes and the velocity of the vehicle as defined by thetrajectory.

The costs of the individual edges may be summed together. In thisregard, returning to the example of FIG. 6 , the costs of each of theedges A, B, C, D, E, F, G, H, I and J may be summed together todetermine an aggregated cost. This aggregated cost may then be combinedwith other costs (including costs of any other no-block zones along thetrajectory) and compared to other aggregated and/or combined costs ofother trajectories in order to assess the overall cost of the trajectoryand compared to other trajectories.

Alternatively, rather than separately assessing the components of costbased on the time the autonomous vehicle will be stopped and the timethe autonomous vehicle will be below a certain threshold speed, a singlesmooth function, inversely correlated with speed may be used to captureboth contributions to cost. In this regard, the cost for each edge of atrajectory that passes through a no-block zone, here C_(edge2), may bedetermined using the following equation:

C _(edge2) =C _(penetration)(target node position)*C _(speed)(targetnode state)*time length of edge

In this example, the target node state represents the speed of theautonomous vehicle for the trajectory when the rear or rear axle of thevehicle traverses the target node for the edge (e.g. the autonomousvehicle has completely traversed the edge). The cost of an edge thattraverses a no-block zone will be higher for lower speeds. In thisregard, for speeds above a certain threshold, the cost should be zero soas to enable passing through the no-block zone. This can be capturedusing an indicator function C_(speed) inversely correlated with speed.For example, the function C_(speed) may be a sigmoid step function, or alinear or exponential equation. FIG. 7 is an example representation of asigmoid step function with a threshold of 10 miles per hour whichrelates speed (in miles per hour) to representative costs according tothe C_(speed) function. In other instances, the shape of the functioncould depend on the type of the no-block zone, such as whether it's astop sign intersection or traffic light intersection, or the vehicle'scurrent driving environment, such as whether there is oncoming/crossingtraffic.

Again, the costs of the individual edges may be summed together. In thisregard, returning to the example of FIG. 6 , the costs of each of theedges A, B, C, D, E, F, G, H, I and J may be summed together todetermine an aggregated cost. This aggregated cost may then be combinedwith other costs (including costs of any other no-block zones along thetrajectory) and compared to other aggregated and/or combined costs ofother trajectories in order to assess the overall cost of the trajectoryand compared to other trajectories.

In some instances, the cost of an edge may also take into account thehysteresis or the historical cost of an edge. This may be used toincentivize (e.g. lower the relative cost of) exiting a no-block zonemore and more over time (across iterations). This can be implemented byhaving edges that leave the no-block zone yield a no-block cost of zerowhile edges that remain in the no-block zone have a higher cost. In thisregard, the cost for each edge of a trajectory that passes through ano-block zone may be determined using one of the following equations:

C _(edge3) =C _(historical) +C _(edge1)

or

C _(edge3) =C _(historical) +C _(edge2)

In this example, the historical cost, here C_(historical), may bedetermined using the using the cost functions above (e.g. C_(edge1) orC_(edge2)) calculated for any portion of the “prior trajectory” (whichmay be the last generated or selected trajectory) within the no-blockzone. In this regard, this may be a cost for a plurality of edges of theprior trajectory that pass through the no-block zone rather than justthe current edge. In this regard, if the vehicle would not be in ano-block zone during the prior trajectory, this value would go to zero.In addition, the C_(historical) can have a maximum value based on thetype in order to prevent the cost from “blowing up” over time anddominating other higher priority costs that are used to evaluate eachtrajectory.

Again, the costs of the individual edges may be summed together. In thisregard, returning to the example of FIG. 6 , the costs of each of theedges A, B, C, D, E, F, G, H, I and J may be summed together todetermine an aggregated cost. This aggregated cost may then be combinedwith other costs (including any costs of other no-block zones along thetrajectory) and compared to other aggregated and/or combined costs ofother trajectories in order to assess the overall cost of the trajectoryand compared to other trajectories.

The features described herein may allow autonomous vehicles to avoidstopping or moving too slowly through no-block zones. In addition, thecost assessments described above may reduce the likelihood of anautonomous vehicle stopping within a no-block zone closer to the centerof the no-block zone. As such, the vehicle may be more likely to stopcloser to edges of the no block-zone rather than making unsafe maneuversin order to avoid stopping within a no-block zone. In addition, becausethe features described herein penalize slower speeds through no-blockzones, this may also cause autonomous vehicles to clear no-block regionseven faster.

Unless otherwise stated, the foregoing alternative examples are notmutually exclusive, but may be implemented in various combinations toachieve unique advantages. As these and other variations andcombinations of the features discussed above can be utilized withoutdeparting from the subject matter defined by the claims, the foregoingdescription of the embodiments should be taken by way of illustrationrather than by way of limitation of the subject matter defined by theclaims. In addition, the provision of the examples described herein, aswell as clauses phrased as “such as,” “including” and the like, shouldnot be interpreted as limiting the subject matter of the claims to thespecific examples; rather, the examples are intended to illustrate onlyone of many possible embodiments. Further, the same reference numbers indifferent drawings can identify the same or similar elements.

1. A method comprising: generating, by one or more processors, atrajectory for an autonomous vehicle to traverse in order to follow aroute to a destination; identifying, by the one or more processors, anarea through which the trajectory traverses; determining, by the one ormore processors, an amount of penetration of the autonomous vehicle intothe area based on the trajectory; and controlling, by the one or moreprocessors, the autonomous vehicle in an autonomous driving modeaccording to the trajectory based on the amount.
 2. The method of claim1, wherein the amount corresponds to how close the autonomous vehicle isto an edge of the area.
 3. The method of claim 1, wherein the area isidentified from predefined in map information and corresponds to an areawithin which the autonomous vehicle should avoid stopping.
 4. The methodof claim 1, wherein the area is defined as a line having a pair ofendpoints.
 5. The method of claim 1, wherein the area is defined as apolygon having three or more edges.
 6. The method of claim 1, whereinthe area is identified by the autonomous vehicle in real time.
 7. Themethod of claim 1, wherein the area includes a railroad crossing.
 8. Themethod of claim 1, wherein the area includes a crosswalk.
 9. The methodof claim 1, wherein the area includes an intersection.
 10. The method ofclaim 1, wherein the area includes a lane of traffic.
 11. The method ofclaim 1, wherein the area includes a no stopping zone.
 12. A systemcomprising one or more processors configured to: generate a trajectoryfor an autonomous vehicle to traverse in order to follow a route to adestination; identify an area through which the trajectory traverses;determine an amount of penetration of the autonomous vehicle into thearea based on the trajectory; and control the autonomous vehicle in anautonomous driving mode according to the trajectory based on the amount.13. The system of claim 12, wherein the amount corresponds to how closethe autonomous vehicle is to an edge of the area.
 14. The system ofclaim 12, wherein the one or more processors are further configured toidentify the area from predefined in map information and the areacorresponds to an area within which the autonomous vehicle should avoidstopping.
 15. The system of claim 12, wherein the area includes arailroad crossing.
 16. The system of claim 12, wherein the area includesa crosswalk.
 17. The system of claim 12, wherein the area includes anintersection.
 18. The system of claim 12, wherein the area includes alane of traffic.
 19. The system of claim 12, wherein the area includes ano stopping zone.
 20. The system of claim 12, further comprising theautonomous vehicle.